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Abstract.  We  describe  a  MIX  cascade  protocol  and  a  reputation  system 
that  together  increase  the  reliability  of  a  network  of  MIX  cascades.  In 
our  protocol,  MIX  nodes  periodically  generate  a  communally  random 
seed  that,  along  with  their  reputations,  determines  cascade  configuration. 
Nodes  send  test  messages  to  monitor  their  cascades.  Senders  can  also 
demonstrate  message  decryptions  to  convince  honest  cascade  members 
that  a  cascade  is  misbehaving.  By  allowing  any  node  to  declare  the  failure 
of  its  own  cascade,  we  eliminate  the  need  for  global  trusted  witnesses. 


Keywords:  anonymity,  reputation,  peer-to-peer,  communal  randomness 

1  Introduction 

Practical  anonymous  communication  systems  require  high  reliability.  Reliability 
can  lead  to  efficiency  because  routes  are  more  likely  to  succeed.  Reliability  can 
also  improve  anonymity  because  senders  need  to  resend  fewer  messages,  and 
because  a  reliable  system  draws  more  users  and  thereby  increases  anonymity 
sets.  Past  approaches  to  increasing  remailer  reliability  have  included  writing 
more  reliable  software  [26] ,  building  MIX  protocols  that  give  provable  robustness 
guarantees  [6, 13,  21],  and  building  a  reputation  system  to  let  users  choose  paths 
based  on  the  published  scores  for  each  node  [7]. 

The  reputation  system  described  in  [7]  uses  a  MIX-net  in  which  nodes  give  re¬ 
ceipts  for  intermediate  messages.  These  receipts,  together  with  a  set  of  witnesses, 
allow  senders  to  verily  the  correctness  of  each  node  and  prove  misbehavior  to 
the  witnesses.  Here  we  investigate  and  solve  two  problems  from  that  design: 

—  The  mechanism  for  verifying  a  failure  claim  requires  a  set  of  global  witnesses, 
a  threshold  of  which  need  to  be  involved  in  confirming  every  failure  claim. 
These  global  witnesses  create  both  a  trust  bottleneck  and  a  communications 
bottleneck.  Our  new  reputation  system  avoids  these  bottlenecks  by  making 
each  node  a  witness  to  its  own  cascade. 

—  An  adversary  trying  to  do  traffic  analysis  can  get  more  traffic  by  gaining 
a  high  reputation.  We  protect  against  such  adversaries  by  choosing  from  a 
pool  of  “acceptable”  MIX  nodes,  and  building  cascades  so  we  can  bound  the 
probability  that  an  adversary  will  control  an  entire  cascade. 
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2  Overview  and  Threat  Model 


We  aim  to  improve  the  reliability  of  anonymous  communication  systems,  en¬ 
abling  their  practical  use  in  fields  such  as  electronic  commerce,  where  trans¬ 
actions  need  to  be  efficient,  reliable  —  and,  frequently,  anonymous.  We  order 
MIX  nodes  into  cascades,  where  each  cascade  presents  a  fixed  path  through  the 
network.  This  approach  allows  us  to  decentralize  the  use  of  witnesses  to  detect 
failure  as  introduced  in  [7],  since  each  node  can  witness  the  traffic  through  its 
own  cascade.  Further,  using  cascades  allows  us  to  better  resist  traffic  analysis 
from  a  pervasive  adversary,  since  sending  traffic  through  fixed  paths  makes  inter¬ 
section  attacks  more  difficult.  Our  reputation  system  gives  users  a  more  accurate 
picture  of  which  nodes  are  currently  up,  allowing  them  to  choose  routes  more 
reliably  and  to  know  what  level  of  protection  they’re  getting. 

Specifically,  we  aim  to  defend  against  two  adversary  goals.  An  anonymity¬ 
breaking  adversary  tries  to  discover  linkability  between  sender  and  receiver;  to 
identify  the  sender  or  receiver  of  a  given  message;  or  to  trace  a  sender  forward 
(or  a  receiver  backward)  to  any  messages.  A  reliability-breaking  adversary  tries 
to  deny  service  to  users.  We  assume  that  our  adversary  can  passively  watch  all 
traffic,  and  can  delay,  modify,  or  insert  some  messages.  We  also  assume  that  the 
adversary  has  compromised  some  fraction  of  the  participating  MIXes. 

Section  4  shows  the  protocol  by  which  MIXes  build  themselves  into  cascades 
in  a  public  and  verifiable  way,  and  also  describes  the  process  of  generating  com¬ 
munal  randomness  so  MIXes  don’t  need  to  trust  a  central  authority  to  build  the 
cascades.  We  periodically  rebuild  cascades  to  reflect  changes  in  reliability. 

Inspired  by  a  comment  by  Jim  McCoy  about  using  reputation  capital  to 
regulate  participants  in  DC- nets  [20],  we  use  a  very  simple  reputation  system. 
Any  member  of  a  cascade  can  declare  its  own  cascade  to  have  failed.  Nodes 
in  a  successful  cascade  each  gain  one  reputation  point,  whereas  all  nodes  in  a 
failed  cascade  lose  one  point.  Nodes  that  misbehave  by  incorrectly  reporting 
cascade  failure  thus  damage  their  own  reputations  too.  We  describe  this  repu¬ 
tation  system  in  Section  5,  including  some  proposals  for  limiting  the  fraction 
of  adversary- controlled  nodes,  a  discussion  of  some  pitfalls  introduced  by  our 
simple  reputation  system,  and  our  technique  for  building  cascades  to  reduce  the 
chance  that  an  adversary  will  control  an  entire  cascade. 

Section  6  describes  our  modified  MIX  cascade  protocol,  and  also  specifies  how 
MIXes  can  decide  when  their  cascade  has  failed.  In  Section  7,  we  describe  a  vari¬ 
ety  of  attacks  on  the  system  and  examine  how  well  our  design  withstands  these 
attacks.  Finally,  we  close  in  Section  8  with  a  discussion  of  possible  directions  for 
future  research. 

3  Related  Work 

3.1  MIX-nets 

Chaum  introduced  the  concept  of  a  MIX- net  for  anonymous  communications  [5] . 
A  MIX-net  consists  of  a  group  of  servers,  called  MIXes  (or  MIX  nodes),  each  of 


which  is  associated  with  a  public  key.  Each  MIX  receives  encrypted  messages, 
which  are  then  decrypted,  batched,  reordered,  stripped  of  the  sender’s  name  and 
identifying  information,  and  forwarded  on.  Chaum  also  proved  security  of  MIXes 
against  a  passive  adversary  who  can  eavesdrop  on  all  communications  between 
MIXes  but  is  unable  to  observe  the  reordering  inside  each  MIX. 

One  type  of  MIX  hierarchy  is  a  cascade.  In  a  cascade  network,  users  choose 
from  a  set  of  fixed  paths  through  the  MIX- net.  Cascades  can  provide  greater 
anonymity  against  a  large  adversary,  because  in  a  free  route  system  an  adversary 
who  owns  many  of  the  MIXes  can  use  intersection  attacks  to  dramatically  reduce 
the  set  of  possible  senders  or  receivers  for  a  given  message  [3]. 

Current  research  on  MIX- nets  includes  stop-and-go  MIX- nets  [16],  distributed 
flash  MIXes  [13],  and  hybrid  MIXes  [23].  MIX  cascade  research  includes  real-time 
MIXes  [15]  and  web  MIXes  [2]. 

3.2  Robustness  and  Reliability  in  MIX-nets 

Previous  work  primarily  investigates  the  robustness  of  MIX-nets  in  the  context 
of  a  distributed  MIX  system  [13].  A  MIX  is  considered  robust  if  it  survives  the 
failure  of  any  k  of  n  participating  servers,  for  some  threshold  k.  This  robustness 
is  all-or-nothing:  either  k  servers  are  good  and  the  MIX  works,  or  they  are  not 
good  and  the  MIX  likely  will  not  work. 

Robustness  has  been  achieved  primarily  via  zero-knowledge  proofs  of  correct 
computation.  Jakobsson  showed  how  to  use  precomputation  to  reduce  the  over¬ 
head  of  such  a  MIX  network  to  about  160  modular  multiplications  per  message 
per  server  [13],  but  the  protocol  was  later  found  to  be  flawed  [21]  by  Mitomo 
and  Kurosawa.  Desmedt  and  Kurosawa’s  alternate  approach  [6]  requires  many 
participating  servers.  Abe’s  MIX  [1]  provides  universal  verifiability  in  which  any 
observer  can  determine  after  the  fact  whether  a  MIX  cheated,  but  the  protocol 
is  still  computationally  expensive.  Neff  recently  made  further  efficiency  improve¬ 
ments  to  universally  verifiable  mixing  [22]. 

Reliability  differs  from  robustness  in  that  we  do  not  try  to  ensure  that  mes¬ 
sages  are  delivered  even  when  some  nodes  fail.  Dingledine  et  al’s  reputation 
system  for  free-route  MIX-net  reliability  [7]  aims  instead  to  improve  a  sender’s 
long-term  odds  of  choosing  a  MIX  path  that  avoids  failing  nodes.  This  work  sim¬ 
ilarly  attempts  to  provide  more  reliable  long-term  service  by  identifying  reliable 
MIXes  and  building  cascades  from  them. 

We  note  that  reliability  and  robustness  can  be  composed:  a  cascade  or  dis¬ 
tributed  MIX  with  robustness  guarantees  can  be  considered  as  a  single  node 
with  its  own  reputation  in  a  larger  MIX-net. 

3.3  Approaches  to  MIX-net  Reliability 

MIX-net  protocols  can  give  specific  guarantees  of  robustness.  Under  suitably 
specified  adversary  models,  these  results  may  be  quite  strong,  e.g.  “this  dis¬ 
tributed  MIX  delivers  correctly  if  no  more  than  half  of  its  participating  servers 
are  corrupt.”  Such  protocols  are  often  complicated  and  inefficient. 


Levien’s  statistics  pages  [19]  present  another  approach.  They  track  both  re¬ 
mailer  capabilities  (such  as  what  kinds  of  encryption  the  remailer  supports)  and 
remailer  up-times,  observed  by  pinging  the  machines  in  question  and  by  send¬ 
ing  test  messages  through  each  machine  or  group  of  machines.  Such  reputation 
systems  improve  the  reliability  of  MIX-nets  by  allowing  users  to  avoid  choosing 
unreliable  MIXes. 

Instead  of  engineering  the  MIX-net  protocol  directly  to  provide  reliability,  we 
make  use  of  reputations  to  track  MIX  performance.  In  this  approach,  we  specify 
a  set  of  behaviors  that  characterize  a  functioning  or  failed  MIX.  We  are  not 
likely  to  prove  strong  theorems  —  the  goal  of  reputation  is  to  make  the  system 
“better”  without  guaranteeing  perfection.  Like  Levien’s  reputation  system  for 
free-route  MIX  networks,  our  published  reputations  enable  users  to  find  better 
routes.  Further,  our  reputation  system  works  behind  the  scenes  to  build  more 
reliable  cascades  —  a  process  that  may  even  be  entirely  transparent  to  the  users. 

Reliability  via  protocol  is  the  most  well-studied  approach,  while  reliability 
via  reputations  in  the  form  of  Levien  statistics  is  the  most  widely  used.  Our 
work  combines  the  two  approaches:  we  modify  the  MIX-net  protocol  to  support 
easier  detection  of  MIX  failures  and  then  specify  a  suitable  reputation  system. 


4  How  to  Randomly  Self-build  Cascades 

We  periodically  rearrange  the  nodes  into  cascades,  so  that  cascades  reflect  recent 
changes  in  reliability,  and  so  nodes  in  failed  cascades  can  get  back  in  a  working 
cascade.  We  choose  to  rearrange  all  nodes,  not  just  those  from  failed  cascades; 
otherwise  reliable  nodes  will  concentrate  in  stable  cascades  and  unreliable  nodes 
in  unstable  ones,  making  it  difficult  for  new  good  nodes  to  gain  reputation. 

Cascades  rebuild  with  period  T  (e.g.,  one  day).  By  T  —  a  —  b,  each  participant 
sends  a  sealed  commitment  to  the  Configuration  Server  ( CS ).  At  T—a—b,  the  CS 
publishes  the  set  of  commitments.  By  T  —  b,  participants  should  reveal  to  the  CS. 

At  T,  the  CS  publishes  the  set  of  reveals,  along  with  the  configuration  of  cascades 
for  that  round.  Observers  can  verify  that  the  CS  followed  the  configuration 
scheme  and  used  the  contribution  from  each  node. 

The  CS  gives  each  node  N  a  signed  receipt  sign  (CS,  [commitment,  timestamp ]). 
The  period  from  T  —  a  —  b  to  T  —  b  should  be  long  enough  that  anyone  within 
reasonable  clock  skew  can  verify  that  the  commitment  phase  has  truly  closed. 
Adequate  time  must  be  allowed  for  nodes  to  submit  their  secrets  and  to  make  use 
of  a  certified  delivery  service  if  their  submissions  are  not  accepted  and  receipts 
provided  by  the  CS  in  a  timely  manner.  The  CS  also  provides  a  receipt  for  the 
reveal.  With  both  receipts,  N  can  prove  that  he  should  be  included  in  the  next 
cascade  configuration. 

Commitment  from  N:  sign (N,  [AT,  IP,  port,  bandwidthpledge,  tsbc(randjv)])- 
Reveal  from  N:  sign(VV,  [TV,  IP,  port, bandwidthpledge. rand^r]) 

Here  “tsbc(randjv)”  is  N’s  temporarily-secret  bit-commitment  to  his  ran¬ 
dom  value  (to  be  explained  below,  in  Section  4.1).  The  CS  then  builds  a  new 


set  of  cascades  for  that  T,  arranged  according  to  an  unpredictable  value  commu¬ 
nally  generated  by  the  participating  mixes.  Thus,  no  one  can  control  the  config¬ 
uration  of  cascades.  Bandwidth  might  be  divided  into  four  categories:  lOKb/s, 
lOOKb/s,  IMb/s,  lOMb/s.  Participants  choose  exactly  one  of  these  values  for 
their  bandwidth  pledge,  and  each  of  the  four  buckets  is  formed  into  a  set  of  cas¬ 
cades  according  to  the  algorithm  described  in  Section  5,  using  the  unpredictable 
communal  value. 

The  communal  value  can  be  used  as  a  seed  to  a  PRNG,  so  the  amount  of 
randomness  required  from  each  participant  is  quite  small.  If  N  is  worried  that 
CS  will  ignore  his  commitment  or  reveal  (not  provide  a  receipt),  he  can  use 
a  certified  mail  delivery  system  [24,  28]  to  convince  other  people  that  CS  is 
misbehaving.  Alternatively,  we  can  build  our  own  certified  delivery  system  by 
pre-assigning  a  set  of  witnesses  (perhaps  fifteen)  from  the  previous  T.  A  threshold 
of  these  witnesses  is  sufficient  to  prove  misbehavior.  As  long  as  the  adversary 
does  not  control  too  high  a  percentage  of  nodes  then  we  can  trust  this  system 
(cf.,  Section  5  for  discussion  of  how  we  limit  this). 

The  set  of  cascades  is  determined  by  the  communal  value  that  is  publicly 
verifiably  committed  when  the  CS  signs  and  posts  the  commitments  and  their 
revealed  values.  Because  a  node  could  still  control  the  resulting  communal  value 
by  choosing  whether  to  reveal  its  value,  the  commitment  is  done  such  that  if  it  is 
not  revealed,  the  CS  can  uncover  it  after  a  predictable  amount  of  computation. 
Any  committed  value  that  is  not  revealed  by  T  —  b  should  be  computed  by  the 
CS  to  be  revealed  at  T. 


4.1  Communal  Randomness  via  Temporarily  Secret  Commitments 

Communal  randomness,  or  more  precisely  a  communally  determined  unpre¬ 
dictable  value,  is  obtained  by  collecting  random  values  from  participating  MIXes. 
These  are  kept  secret  until  everyone  has  committed  so  that  no  one  can  predict 
the  result  of  combining  them.  The  committed  values  can  be  uncovered  without 
help  from  the  committers  if  necessary  so  that  no  one  can  alter  the  communal 
result  in  a  predictable  way  by  failing  to  reveal  what  she  committed.  On  the  other 
hand,  not  all  the  committed  random  values  can  be  uncovered  by  an  adversary 
in  time  for  him  to  craft  a  commitment  that  will  yield  a  predictable  result. 

Various  approaches  to  this  capability  have  been  published.  In  [11],  the  com¬ 
mitted  unpredictability  comes  from  a  long  “delaying”  calculation  on  the  result 
of  a  (fast)  combination  of  the  inputs  from  participants.  Another  similar  scheme 
is  given  in  [27].  Both  [4]  and  [27]  give  commitment  schemes  that  are  individual, 
as  here;  [4]  also  describes  a  zero-knowledge  proof  of  a  well-formed  commitment. 
[12]  further  expands  and  develops  the  work  in  [11]  and  [27]. 

We  follow  the  individual  commitment  approach  of  [12,  27]  because  it  is  both 
shortcut  computable  and  easily  commitment-verifiable.  Anyone  possessing  a  se¬ 
cret  (in  this  case  the  committer)  can  compute  the  committed  result  quickly.  Once 
the  committed  value  is  revealed,  anyone  can  easily  check  that  this  is  the  commit¬ 
ted  value.  Commitments  take  the  form  tsbc(randjv)  =  (enc(A',  randjy),  w(K)), 


the  encryption  of  randjy  with  K  followed  by  a  TSBC  function  used  to  com¬ 
mit  to  K .  [25]  presents  a  function  such  that  the  committer  N  can  quickly  and 
easily  calculate  w(K)  as  well  as  enc(A', randjv)-  Once  K  has  been  revealed  (or 
calculated)  for  each  of  the  entries,  all  the  keys  can  be  published  by  the  CS. 
Anyone  can  quickly  verify  the  communal  unpredictable  value  by  performing  the 
encryptions  and  computing  their  amalgamation. 

Neither  shortcut  computability  nor  easy  commitment-verifiability  hold  for 
the  collective  commitment  that  first  appeared  in  [11].  The  application  of  com¬ 
mitments  to  communal  unpredictability  is  not  the  central  focus  of  [4]  and  is 
only  described  briefly.  It  is  also  only  described  for  two  parties  producing  a  ran¬ 
dom  bit;  thus  only  one  commitment  from  one  party  is  needed  to  run  the  proto¬ 
col.  With  multiple  parties  committing  to  many  bits,  malleability  of  the  timed- 
commitments  [9]  may  become  a  factor  if  the  revealed  values  are  simply  XORed 
together  to  produce  the  result.  The  well-formedness  proofs  may  ultimately  play 
a  role  in  the  non-malleability  of  the  commitments  since  this  is  similar  to  how 
non- malleability  of  commitments  is  proved;  we  leave  this  as  future  work.  Instead, 
we  avoid  the  issue  of  malleability  by  ensuring  that  the  amalgamation  of  the  re¬ 
vealed  values  is  not  affected  by  correlations  among  those  revealed  values.  For 
example,  if  the  revealed  values  are  concatenated  in  the  order  the  commitments 
were  posted  and  then  hashed  with  a  well-designed  hash  function,  the  result 
should  be  unpredictable  if  even  one  of  the  committed  values  is  unpredictable. 

We  could  make  use  of  the  well-formedness  proofs  in  [4]  to  prevent  nodes 
from  submitting  malformed  commitments  without  detection,  but  the  computa¬ 
tional  overhead  is  not  necessary.  Whether  a  commitment  is  malformed  can  be 
confirmed  after  a  predictable  amount  of  computation.  Once  it  is  known  to  be 
malformed,  the  result  can  either  be  discarded  or  it  can  be  used  as  if  it  had  been 
well- formed  (details  in  [12,  27]).  Because  inputs  come  from  nodes  with  a  vested 
interest  in  maintaining  reputation,  we  can  use  the  reputation  system  to  ensure 
that  malformed  commitments  are  rare.  All  nodes  must  commit  to  participate 
in  the  network,  but  to  minimize  the  number  of  malformed  inputs  or  committed 
but  not  overtly  revealed  inputs,  only  commitments  from  high  reputation  nodes 
will  contribute  to  the  communal  unpredictable  value.  We  might  use  inputs  from 
the  top  half  of  the  nodes  (all  bandwidths),  to  make  sure  we  have  enough  inputs 
to  make  collusion  or  compromise  of  the  result  unlikely.  Any  node  that  commits 
but  does  not  reveal  or  puts  in  a  malformed  commitment  loses  reputation.  To 
minimize  ongoing  problems  from  a  misbehaving  node,  the  random  input  from 
that  node  is  not  used  for  a  fixed  number  of  subsequent  rounds. 

If  all  nodes  contributing  to  the  communal  value  have  revealed  secret  values 
that  can  be  verified  as  committed  during  the  entry  phase,  these  can  be  combined 
by  whatever  means  we  use  to  yield  a  random  result,  e.g.,  concatenation  and 
hashing  as  above.  If  not,  we  use  the  delaying  calculation  to  uncover  those  not 
revealed.  If  all  such  revealed  values  correspond  to  well-formed  TSBC  entries,  the 
result  still  remains  easily  commitment  verifiable.  If  any  of  them  are  malformed, 
the  communally  determined  value  will  only  be  verifiable  by  the  corresponding 


delaying  calculation  (with  parallel  or  probabilistic  speedup,  once  it  has  been 
done  initially,  cf.  [12,27]  for  details). 

5  Reputation  System  and  Cascade  Configuration 

We  would  like  to  develop  as  simple  a  scoring  system  as  possible  —  simple  sys¬ 
tems  are  easier  to  analyze  for  security,  and  they  allow  the  users  to  more  easily 
understand  the  implications  of  a  given  score.  Our  system  decrements  the  reputa¬ 
tion  of  all  nodes  in  a  failed  cascade,  and  increments  the  reputation  of  all  nodes  in 
a  successful  cascade.  Thus  we  don’t  have  to  worry  about  pinpointing  the  cause 
of  failure.  The  hope  is  that  reputations  will  give  a  general  sense  of  the  reliability 
of  nodes  over  the  long  term. 

However,  because  a  node’s  behavior  affects  the  reputation  of  its  cascade- 
mates,  this  introduces  a  new  attack  on  the  reputation  system.  When  a  cascade 
fails  that  has  fewer  bad  nodes  than  good  nodes,  it  does  more  damage  to  the 
overall  reputation  of  good  nodes  than  bad.  Since  bad  nodes  can  intentionally 
fail  a  cascade,  they  can  exploit  this  vulnerability  to  gradually  reduce  the  relative 
reputation  of  the  good  nodes.1  The  bad  nodes  “creep  upward”  on  the  reputation 
spectrum,  eroding  the  reputation  of  nodes  above  them  —  our  visual  simulations 
led  us  to  refer  to  this  attack  as  the  creeping  death. 

Because  the  bad  nodes  can  gain  reputation  faster,  they  can  eventually  get 
to  any  point  on  the  reputation  scale.  Rather  than  complicating  the  reputation 
system  to  prevent  our  adversary  from  performing  the  creeping  death  attack,  we 
intentionally  keep  it  simple  and  develop  an  algorithm  for  building  cascades  that 
minimizes  impact  from  this  attack. 

Since  bad  nodes  can  position  themselves  anywhere  (reputation-wise)  to  in¬ 
crease  the  chance  of  winning  a  whole  cascade,  the  optimal  strategy  to  protect 
anonymity  chooses  nodes  for  each  cascade  entirely  at  random.  But  we  also  want 
to  increase  the  cost  of  reliability  breaking,  so  that  the  adversary  can  only  affect 
cascades  likely  to  be  highly  desired  for  use  if  he  runs  reliable  nodes  himself; 
simply  getting  nodes  into  the  system  should  have  less  impact.  We  thus  combine 
these  approaches  and  begin  choosing  cascade  nodes  randomly  (using  the  random 
seed  from  the  method  of  Section  4)  from  an  adequately  large  set  of  nodes,  but 
still  of  the  highest  possible  reputation.  (See  Section  5.1  for  details.) 

While  the  reputation  system  reduces  the  impact  of  an  adversary  that  merely 
gets  nodes  accepted  into  the  system,  the  creeping  death  attack  allows  a  resource¬ 
ful  adversary  to  quickly  move  up  on  the  reputation  spectrum.  An  adversary  with 
many  nodes  can  still  succeed  at  breaking  reliability  and  anonymity.  We  prevent 
our  adversary  from  creating  a  multitude  of  identities  and  flooding  the  system 
with  them  (an  attack  known  as  pseudospoofing)  with  an  identity-based  barrier 
to  entry:  a  web  of  trust  like  Advogato  [17].  A  web  of  trust  allows  us  to  limit 
the  number  of  nodes  an  adversary  can  get  certified.  [17]  gives  a  proof  that  the 

1  ‘Good’  and  ‘bad’  refer  to  nodes  that  are  honest  or  that  are  part  of  the  adversary, 
respectively.  Because  a  bad  node  may  be  reliable  to  break  anonymity  or  reliability, 
they  do  not  necessarily  correspond  to  ‘reliable’  and  ‘unreliable’. 


number  of  bad  nodes  accepted  by  the  web  is  limited  by  the  number  of  honest 
members  that  might  assign  trust  to  the  adversary  ( confused  nodes)  —  not  the 
number  of  nodes  the  adversary  creates.  If  we  pick  the  seeds  of  the  web  carefully 
and  make  some  assumptions  about  the  number  and  position  of  confused  nodes, 
we  can  bound  the  fraction  of  bad  nodes  in  the  system. 

Alice  should  certify  Bob  based  on  whether  she  believes  him  to  be  trustwor¬ 
thy  (to  be  a  real  person  with  good  intentions).  If  she  certifies  based  on  expected 
performance,  the  adversary  can  simply  run  convincingly  reliable  nodes.  Certifi¬ 
cation  aims  only  to  bound  the  total  percentage  of  adversary-owned  nodes  in  the 
system. 

On  the  other  hand,  we  might  ask  Alice  to  not  certify  Bob  if  she  believes  he 
might  be  unreliable.  However,  this  imposes  a  greater  burden  on  Alice,  and  also 
doesn’t  account  for  the  fact  that  Bob’s  behavior  can  change  over  time  (whereas 
certification  is  a  one-time  event).  Instead,  the  reliability  of  an  admitted  node 
will  be  determined  by  the  reputation  system.  Nodes  that  are  the  most  reliable 
over  time  will  have  the  highest  reputations. 


5.1  Building  Cascades 

It  is  tempting  to  believe  that  some  alternative  reputation  system  or  cascade 
algorithm  can  reduce  or  simplify  the  problem  introduced  by  creeping  death.  For 
instance,  we  might  punish  nodes  incrementally  more  as  they  have  more  failures 
on  record.  But  this  is  exactly  the  problem  —  honest  nodes  do  fail  more  often  than 
adversary  nodes.  For  any  pattern  that  we  look  for,  our  adversary  can  arrange  it 
so  honest  nodes  fit  that  pattern  better  or  more  often  than  bad  nodes. 

Consider  cascades  with  only  two  nodes.  In  cascades  with  one  good  and  one 
bad,  the  bad  node  can  hurt  only  one  good  node,  so  by  construction  bad  nodes 
do  equal  damage  to  good  nodes.  But  even  this  system  falls  prey  to  the  creeping 
death.  Since  a  cascade  can  only  fail  if  one  of  its  nodes  writes  the  “We  failed” 
certificate,  the  both-bad  case  will  never  fail  (the  nodes  simply  never  write  the 
certificate),  whereas  a  both- good  case  will  sometimes  legitimately  fail.  Thus  ev¬ 
ery  both-bad  cascade  can  stop  functioning  immediately,  yet  the  bad  reputations 
increase  faster  than  the  good  reputations  over  time. 

While  we  cannot  easily  reduce  or  prevent  creeping  death,  we  can  choose  cas¬ 
cades  to  produce  acceptable  and  predictable  risk  and  reliability  despite  creep¬ 
ing  death.  Reasonable  anonymity  protection  may  require  chaining  cascades  into 
longer  paths. 

We  order  the  nodes  by  reputation,  and  choose  nodes  for  the  first  cascade 
randomly  from  within  a  pool  of  nodes  at  the  top  of  the  reputation  spectrum. 
(Randomness  is  obtained  from  the  seed  chosen  in  the  method  of  Section  4.1.) 
Next,  add  to  the  pool  enough  next-highest  reputation  nodes  to  maintain  its  size 
and  pick  another  cascade  at  random.  This  continues  until  the  last  cascade  for 
which  an  adequate  pool  size  can  be  maintained.  At  that  point,  the  remaining 
nodes  are  formed  into  cascades  at  random. 

How  do  we  decide  this  pool  size?  Assume  the  following  notation: 


—  p  =  fraction  of  nodes  that  are  bad, 

—  s  =  scare  factor:  acceptable  probability  of  adversary-controlled  path, 

—  r  =  range:  size  of  the  pool  from  which  nodes  are  chosen  for  a  single  cascade, 

—  I  =  length  of  a  single  cascade, 

—  c  =  chain  length:  number  of  cascades  chained  together, 

For  determining  the  range,  we  assume  a  worst  case  for  adversary  distribution, 
because  of  creeping  death.  That  is,  we  always  assume  the  adversary  resides 
entirely  in  the  pool  of  nodes  from  which  we’re  picking  a  cascade.  This  means 

fP\lc  a  P 

-  =  s  and  so  r  = 
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For  example,  suppose  that  cascades  are  of  length  4,  there  are  not  more  than 
20%  bad  nodes  altogether,  and  it  is  acceptable  that  one  of  every  hundred  thou¬ 
sand  paths  (cascade  chains)  is  completely  bad  —  meaning  messages  through  it 
are  compromised.  Also  assume  that  we  chain  three  cascades  to  reduce  the  odds 
that  all  nodes  traversed  are  bad.2  Then 


r  = 


.2 

(10-5)T2 


0.522 


Thus  the  first  cascade  must  come  from  nodes  in  the  top  52.2%  of  the  repu¬ 
tation  spectrum.  The  next  cascade  must  be  chosen  from  the  same  pool,  minus 
the  four  nodes  of  the  first  cascade  and  plus  the  four  next  highest  reputation 
nodes.  Once  the  lowest  reputation  node  has  been  added  to  the  choice  pool,  the 
remaining  nodes  are  just  chosen  at  random  until  all  the  cascades  are  formed. 

A  chained  cascade  path  is  the  same  as  a  single  long  cascade  of  length  Ic  with 
respect  to  the  odds  that  all  nodes  in  it  are  bad,  but  they  are  not  the  same  in 
general.  When  a  chained  cascade  fails,  only  the  offending  subcascade  is  removed 
from  the  system  for  that  period  and  its  nodes  decremented  in  reputation.  Also, 
users  may  choose  to  chain  cascades  or  not,  may  not  always  choose  to  chain  in 
the  same  way,  or  may  choose  a  longer  or  shorter  chain.  A  user  may  choose  not  to 
chain  because  of  the  computational  overhead,  the  latency,  etc.  This  choice  will 
afford  him  improvements  in  those  areas,  but  at  an  increased  risk  to  anonymity. 
Users  should  be  made  aware  of  the  risks.  Our  system  allows  an  easy  explicit 
presentation  of  the  relative  risks  and  tradeoffs.  It  also  allows  us  to  adjust  these 
at  the  system  level.  For  example,  if  we  wish  to  reduce  r,  we  can  weaken  s,  or 
adjust  l  or  the  recommended  c.  Of  course  if  p  is  high  enough,  s  strong  enough, 
and  we  limit  Ic  to  some  practical  bound,  r  may  exceed  1  and  no  network  is 
feasible.  Or  r  may  be  close  enough  to  1  to  render  the  reputation  system  largely 
moot  —  but  at  least  we  can  calculate  this  and  react  accordingly. 

2  A  path  length  of  12  would  be  absurd  with  current  remailers;  but  the  whole  point  of 
this  design  is  to  improve  reliability  so  long  paths  are  feasible. 


6  The  Cascade  Protocol,  or,  When  to  Fail  Your  Cascade 

Opportunies  for  misbehavior  in  cascades  fall  into  three  classes: 

1.  Entry  point:  Incoming  messages  might  not  be  accepted. 

2.  Inside  the  cascade:  Messages  might  be  replaced  with  dummy  messages. 

3.  Exit  point:  Messages  might  not  be  delivered. 

Each  MIX  can  test  its  cascade  by  sending  and  receiving  messages  using 
ordinary-looking  external  addresses  —  but  spoofing  or  maintaining  plausible 
external  addresses  is  hard.  Instead,  we  protect  against  this  “selectively  process 
the  test  messages”  attack  by  relaying  traffic  through  other  nodes  in  the  cascade 
and  allowing  them  to  undetectably  insert  test  messages.  All  l  nodes  in  the  cas¬ 
cade  (typically  l  might  be  4  or  5)  accept  j  of  the  total  traffic,  and  deliver  the 
messages  to  the  head  of  the  cascade.  The  head  publishes  a  snapshot  of  the  batch 
(a  set  of  hashes  of  each  message)  as  he  processes  it. 

A  sender  Alice  can  ask  for  the  snapshot  to  verify  that  her  message  got  into 
the  batch.  If  not,  she  concludes  that  either  the  head  or  the  node  she  used  was 
dishonest,  and  goes  to  a  different  node  or  cascade.  As  an  optimization,  nodes 
that  accept  messages  can  give  Alice  a  receipt  if  they  accept  her  message.  If  her 
message  does  not  make  it  into  the  batch,  Alice  can  broadcast  the  message  and 
the  receipt  to  the  other  nodes  in  the  cascade;  an  honest  cascade  member  will 
determine  that  the  receipt  should  have  been  honored  and  fail  the  cascade. 

Because  all  the  messages  to  the  head  come  from  other  nodes  in  the  cascade, 
these  nodes  can  insert  indistinguishable  test  messages  into  the  batches.  If  a 
test  message  does  not  make  it  to  the  tail,  its  sender  fails  the  cascade.  Since 
other  nodes  can’t  tell  which  messages  are  test  messages,  dishonest  nodes  risk 
being  caught  if  they  replace  even  one  message  with  a  dummy  message.  Thus  our 
protocol  detects  misbehavior  at  the  entry  point  (Goal  1). 

In  the  naive  delivery  design,  the  tail  delivers  messages  and  also  broadcasts 
them  to  the  other  nodes  in  the  cascade.  Every  node  attempts  delivery.  Since 
the  tail  can’t  tell  who  wrote  a  test  message,  he  must  deliver  every  message 
to  every  node  in  the  cascade  or  risk  failing  the  cascade.  To  prevent  the  tail 
from  selectively  dropping  messages  based  on  destination,  nodes  address  some 
of  their  test  messages  to  previous  recipients.  Thus,  the  tail  must  deliver  even 
to  a  user  not  known  to  be  running  a  node.  (This  reliability  increase  must  be 
balanced  with  possible  spam  abuse.)  A  more  efficient  design  assumes  a  PKI 
which  includes  all  recipients.  In  this  case,  we  shortcut  the  need  for  broadcasting 
when  the  original  delivery  attempt  produces  a  signed  receipt;  we  discuss  this 
more  in  Section  6.1.  By  delivering  outgoing  traffic  to  all  cascade  members,  our 
protocol  detects  misbehavior  at  the  exit  point  (Goal  3). 

A  dishonest  head  can  publish  a  correct  batch  snapshot  but  replace  its  (or  a 
conspirator’s)  portion  of  messages  with  dummy  messages.  Because  it  knows  its 
portion  contains  no  test  messages,  all  of  those  messages  will  be  undetectably  lost. 
We  solve  this  by  supporting  external  test  messages  as  well.  Alice  might  become 
suspicious  because  the  cascade  accepts  messages  but  doesn’t  deliver  them;  she 


can  send  a  test  message,  wait  a  while,  and  then  reveal  to  everybody  how  the 
message  should  have  decrypted.  If  at  least  one  node  in  the  cascade  is  honest,  he 
will  agree  that  he  didn’t  see  the  message  and  fail  the  cascade.  Thus  we  detect 
misbehavior  after  the  batch  snapshot  is  published.  (Goal  2). 

Senders  may  want  to  chain  cascades  for  stronger  anonymity.  To  make  chain¬ 
ing  cascades  more  robust,  nodes  consider  delivery  to  a  second  cascade  as  a  special 
case.  We  can  specify  the  entire  cascade  rather  than  a  single  node  as  the  next 
hop  in  the  chain.  Each  node  from  the  first  cascade  chooses  a  random  node  in 
the  second  cascade  and  attempts  delivery.  Nodes  may  verify  that  their  message 
is  included  in  the  next  cascade’s  batch,  and  claim  misbehavior  if  not.  With  this 
modification,  the  head  of  a  cascade  must  be  able  to  detect  duplicates  in  the 
batch;  however,  since  all  nodes  must  already  detect  duplicates  to  foil  replays, 
this  presents  no  extra  burden. 

Since  senders  exposing  a  faulty  cascade  have  no  reason  to  chain  their  test 
messages  through  another  cascade,  some  nodes  need  to  explicitly  send  external 
test  messages  to  other  cascades  and  verify  their  delivery. 

Test  messages  using  real  addresses  help  foil  time-based  intersection  attacks. 
In  a  standard  MIX  network,  an  adversary  with  information  about  what  users  are 
active  at  what  times  can  quickly  narrow  down  the  set  of  suspects  based  on  when 
traffic  is  seen.  An  active  adversary  works  even  faster  by  knocking  out  suspects 
until  traffic  stops.  Because  cascade  nodes  send  messages  too,  an  address  might 
get  mail  at  other  times  as  well. 

Users  worried  about  profiling  should  send  each  message  through  a  different 
cascade,  so  an  adversary  who  owns  a  few  cascades  cannot  read  all  messages. 
Users  worried  about  message  linkability  should  send  all  messages  through  one 
cascade:  a  single  compromised  cascade  can  reveal  linkability. 

A  decentralized  algorithm  would  allow  users  to  keep  a  similar  anonymity  set 
across  cascade  reconfigurations,  further  blocking  time-based  intersection  attacks. 
On  the  other  hand,  an  adversary  targetting  a  specific  user  benefits  from  this 
predictable  behavior.  We  leave  this  as  future  work. 

Plaintext  messages  are  distinguishable  and  so  are  less  reliable.  Further,  since 
test  messages  with  convincing  plaintext  are  hard  to  write,  nodes  are  unlikely  to 
address  tests  to  a  recipient  without  a  known  public  key.  Optionally,  outside  users 
could  contribute  convincing  plaintext  messages  to  be  used  as  test  messages  by  a 
node;  that  way  it  could  send  a  plaintext  test  message  to  the  recipient  and  verify 
its  delivery. 


6.1  Delivery  Receipts 

Message  recipients  can  give  the  tail  a  receipt  when  he  delivers  a  message.  The 
tail  first  attempts  to  get  a  receipt,  which  he  can  use  to  prove  that  he  delivered 
the  message.  If  he  does  not  get  a  receipt  (e.g.,  because  the  destination  address 
refuses  to  provide  a  receipt  or  does  not  exist),  he  broadcasts  the  message  to  the 
other  members  of  the  cascade,  who  try  to  deliver.  In  any  case  they  now  know 
that  he  followed  the  protocol. 


An  unhappy  sender  Alice  can  contact  some  cascade  node  N  and  claim  “T 
didn’t  deliver  my  message” ,  along  with  a  demonstration  of  the  remaining  de¬ 
cryptions  between  N  and  T.  If  N  remembers  what  he  passed  to  N  +  1 ,  Alice 
can  show  N  what  it  should  have  looked  like  when  it  got  to  T. 

If  N  has  already  heard  from  T  about  its  attempt  to  deliver  the  message,  he 
knows  T  is  blameless.  If  not,  he  can  query  T  for  a  receipt  —  if  T  has  no  receipt, 
the  cascade  failed  (either  the  message  never  got  to  T,  or  he  did  not  deliver  it). 

Delivery  receipts  detect  misbehavior  as  long  as  one  of  the  nodes  in  the  cascade 
is  honest.  If  the  honest  node  is  the  tail  T  and  the  message  makes  it  that  far, 
then  the  message  will  be  delivered  (cases  1  and  2  handle  if  the  message  doesn’t 
make  it  that  far).  If  T  is  bad,  either  he  delivers  the  message  to  an  honest  N  and 
it  gets  delivered,  or  he  does  not  and  Alice  can  convince  N  that  the  cascade  is 
misbehaving. 

If  a  recipient  is  not  configured  to  return  a  receipt,  the  delivery  still  gets 
through  —  in  this  case,  the  message  gets  broadcast  to  the  other  cascade  mem¬ 
bers,  and  each  of  them  attempts  delivery.  In  a  sense,  the  use  of  receipts  is  just 
a  bandwidth  optimization. 

Most  related  work  assumes  public  keys  for  recipients  are  known  to  all  parties. 
Without  this  PKI,  the  exit  node  can  forge  a  signed  receipt  from  the  recipient. 
But  since  we  don’t  need  to  link  keys  to  external  identities,  a  sender  Alice  can 
include  Bob’s  signature  verification  key  in  her  message,  allowing  any  cascade 
node  to  verify  Bob’s  receipt  in  a  decentralized  fashion. 

6.2  Capacity-attacking  Adversary 

Since  nodes  can  refuse  incoming  messages  by  falsely  claiming  to  be  full,  the 
number  of  messages  processed  by  a  cascade  is  at  least  proportional  to  the  number 
of  honest  nodes  in  that  cascade.  By  inserting  indistinguishable  test  messages  into 
its  own  batches,  each  node  verifies  that  the  rest  of  the  cascade  is  successfully 
decrypting  and  passing  on  that  fraction  of  its  bandwidth  promise,  as  well  as 
guaranteeing  that  the  batch  provides  a  minimum  level  of  anonymity.  Nodes 
should  pad  if  they  don’t  have  a  full  batch  fraction;  by  failing  the  cascade  if  the 
amount  of  traffic  coming  in  from  the  previous  hop  is  outside  suitable  thresholds, 
each  node  verifies  that  the  rest  of  the  cascade  is  spending  (even  if  wasting)  its 
entire  bandwidth  promise. 

By  not  accepting  any  messages  and  then  not  delivering  the  corresponding 
dummy  traffic,  bad  nodes  can  spend  slightly  less  bandwidth  than  good  nodes. 
But  if  those  bad  nodes  are  delivering  messages  for  the  honest  cascade  members, 
they  are  doing  no  more  damage  than  if  they  simply  had  not  signed  up  that 
period.  Thus  our  design  frustrates  a  capacity-breaking  adversary  (a  special  case 
of  the  reliability- breaking  adversary). 

6.3  Resource  Management  and  Reputation  Servers 

Because  the  highest-reputation  cascade  cannot  process  all  of  the  traffic,  cascades 
publish  available  capacity  information,  including  the  expected  wait  or  available 


quality  of  service  for  messages.  Users  compare  reputation  and  available  QoS  from 
each  cascade,  thus  balancing  load  across  the  cascades. 

A  group  of  redundant  reputation  servers  ( RS )  serve  current  node  state.  Nodes 
give  each  RS  hourly  heartbeat  updates,  and  deliver  failure  messages  immediately. 
Because  each  node  signs  and  timestamps  each  certificate,  an  RS  can  at  most  fail 
to  provide  the  newest  certificate.  Each  RS  works  with  the  others  to  ensure  correct 
data,  perhaps  by  successively  signing  certificate  bundles.  Senders  download  the 
entire  bundle  of  certificates  if  it  is  small  enough,  else  they  must  query  through  the 
MIX-net  or  query  via  Private  Information  Retrieval  [18]  to  privately  download 
a  random  subset.  Otherwise,  the  adversary  could  use  that  information  to  aid 
intersection  attacks. 

Actual  deployment  is  still  a  complex  problem;  we  leave  this  as  future  work. 


7  Attacks  and  Defenses 

Attacks  on  Anonymity 

Have  enough  nodes  to  own  an  entire  cascade.  By  using  a  web  of  trust,  building 
cascades  from  a  large  enough  pool  of  reliable  nodes,  and  suggesting  a  safe 
minimum  chain  length,  we  control  the  chance  that  this  attack  will  succeed. 

Gain  high  reputation  to  read  more  traffic.  Similarly,  our  cascade  building  algo¬ 
rithm  blocks  this  attack. 

Replay  attack,  message  delaying,  etc.  We  rely  on  the  standard  defenses  offered 
by  MIX-net  protocols. 

Trickle  attack.  If  one  node  in  the  cascade  is  honest,  at  least  j  of  the  traffic  will 
be  legitimate  in  every  batch. 

Intersection  attack.  Using  MIX  cascades  rather  than  free  routes  helps  to  defend 
against  intersection  attacks  from  very  large  adversaries  [3].  By  encouraging 
users  to  pad  with  dummy  messages  when  not  sending  traffic,  and  to  continue 
using  similar  anonymity  sets  across  cascade  configurations,  we  can  further 
complicate  intersection  attacks.  However,  a  complete  solution  to  the  inter¬ 
section  attack  remains  an  open  problem. 

Influence  cascade  configuration  externally.  Our  algorithm  for  generating  com¬ 
munally  random  uncertainty  resists  individuals  and  groups,  as  detailed  in 
Section  4. 

Compromise  the  cascade  configuration  server.  Because  the  output  of  the  CS  is 
publicly  verifiable,  incorrect  behavior  can  be  detected. 

Knock  down  uncompromised,  cascades  to  get  more  traffic.  While  the  adversary 
can  knock  down  other  cascades,  the  low  chance  of  owning  an  entire  path 
limits  the  success  of  this  attack. 

Attacks  on  Capacity  and  Reliability 

Flood  nodes  with  messages.  If  this  becomes  a  problem,  we  can  integrate  a  ticket 
service  such  as  that  in  [2] ,  limiting  the  number  of  messages  a  given  identity 
can  generate  for  each  batch.  Other  solutions  include  proofs  of  work  and  other 
micropayment  schemes  [8, 10, 14]. 


Knock  down  many  cascades.  We  assume  that  our  adversary  is  not  strong  enough 
to  knock  down  all  or  most  of  the  cascades  in  the  system.  If  he  only  knocks 
down  some,  service  continues  as  normal. 

Block  commitments  to  the  Configuration  Server.  If  the  adversary  launches  a 
denial  of  service  attack  against  the  CS,  the  participants  can  together  use  a 
decentralized  algorithm  to  simulate  the  CS  (all  of  its  operations  are  public 
and  verifiable). 

Flood  the  CS  with  commits.  We  only  consider  commits  from  nodes  which  have 
been  certified  in  the  web  of  trust,  and  we  only  need  to  actually  use  those 
commitments  from  relatively  high-reputation  nodes. 

Refuse  commitments  at  the  Configuration  Server.  Because  we  allow  certified 
delivery  to  the  CS,  refusing  commitments  can  be  detected  by  any  observer. 

Refuse  incoming  messages  as  a  cascade  member.  This  attack  can  work  to  reduce 
capacity;  but  the  node  is  still  spending  most  of  its  pledged  bandwidth  on 
correctly  processing  messages  from  other  nodes,  as  well  as  generating  dummy 
traffic  in  place  of  the  refused  traffic.  This  attack  is  very  inefficient. 

Selectively  process  only  test  messages.  Our  protocol  addresses  this  possibility 
in  Section  6. 

Attacks  on  Reputations 

Beat  the  web  of  trust.  The  security  of  the  web  of  trust  is  perhaps  the  most  criti¬ 
cal  assumption  of  our  system.  If  an  adversary  can  get  a  lot  of  nodes  certified 
without  spending  effort  for  each  one,  he  can  start  widespread  attacks  on 
anonymity,  reliability,  capacity,  and  reputations.  On  the  other  hand,  getting 
just  a  few  extra  nodes  certified  does  not  buy  him  much. 

Internal  selective  DoS  —  creeping  death.  The  adversary  can  use  the  creeping 
death  attack  (fail  the  cascade  if  good  nodes  lose  more  reputation  than  bad 
nodes)  to  gain  any  position  in  the  reputation  spectrum.  Our  cascade  building 
algorithm  makes  this  technique  ineffective  at  breaking  anonymity;  further, 
it  may  prove  very  expensive  in  terms  of  resources  to  move  a  large  number  of 
nodes  to  the  top  of  the  reputation  spectrum. 

External  selective  DoS  —  knock  down  the  high-reputation  cascades.  Our  “all 
for  one  and  one  for  all”  approach  to  reputation  makes  selective  denial  of 
service  even  easier  than  in  [7].  Previously,  to  knock  down  a  reliable  node  you 
needed  to  successfully  flood  it  or  cause  it  to  not  process  messages  correctly. 
Now  you  simply  have  to  locate  and  knock  down  the  weakest  member  of 
its  cascade.  However,  this  vulnerability  is  acceptable:  removing  one  cascade 
does  not  deny  service  to  the  system  as  a  whole,  and  as  above  it  does  not  get 
you  much  closer  to  breaking  anonymity. 

8  Future  Directions 

We  have  described  a  protocol  for  improving  reliability  of  anonymous  communi¬ 
cation  networks,  based  on  a  MIX  cascade  design  and  a  simple  reputation  system. 

There  are  a  number  of  directions  for  future  research: 


—  Better  approaches  to  generating  convincing  destinations  for  dummy  traffic, 
or  reducing  the  bandwidth  overhead  of  the  current  approaches,  would  make 
the  overall  design  more  reasonable. 

—  Improved  cascade  configuration  algorithms  would  allow  us  to  provide  stronger 
anonymity  and  reliability. 

—  More  research  on  the  scope  and  characteristics  of  the  creeping  death  attack 
might  give  insight  on  how  to  defeat  it. 

—  More  analysis  on  the  attack-resistance  of  our  reputation  system  might  yield 
stronger  proofs  or  a  better  design.  For  instance,  can  we  guarantee  bounds 
on  work  performed  by  the  adversary  under  various  models? 

—  Adapting  this  design  to  free-route  MIX  networks  would  allow  it  to  be  tested 
with  a  wider  deployment  in  the  current  remailer  system. 
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